1. Field of the Invention
The present invention relates generally to an apparatus and a method for implementing handoff between heterogeneous networks in a wireless communication system, and in particular, to an apparatus and a method for implementing handoff between an Institute of Electrical and Electronics Engineers (IEEE) 802.11 network and an IEEE 802.16 network.
2. Description of the Related Art
The providing of services with diverse Quality of Service (QoS) levels at about 100 Mbps is an ongoing research area for a future-generation communication system, namely, a 4th Generation (4G) communication system. The existing 3rd Generation (3G) communication systems support approximately 384 kbps in a relatively poor outdoor channel environment and at most 2 Mbps in a relatively good indoor channel environment. Wireless Local Area Network (WLAN) and Wireless Broadband (WiBro) systems typically support 20 Mbps to 50 Mbps. In this context, studies have actively been conducted on guarantee of  mobility and QoS for WLAN and WiBro supporting relatively high rates in the 4G communication system.
One of the studies concerns handoff between heterogeneous networks, WLAN and WiBro (or broadband wireless communication system). Generally, handoff refers to homogeneous handoff. However, the IEEE 802.21 working group is developing standards to enable handoff between heterogeneous networks, this inter-technology handoff will be provided seamlessly in the 4G communication system.
The IEEE 802.11 Task Group (TG) f deals with support of handoff between 802.11 Access Points (APs) and the IEEE 802.11 standards which defines only handoff-associated messages. Typically, the cell coverage of an IEEE 802.11 network ranges within tens to hundreds of meters, and an IEEE 802.16 network reaches a few kilometers. Thus, it is meaningless to separate the two networks. The IEEE 802.11 APs are expected to increase the capacity of IEEE 802.16 Base Stations (BSs) or cover shadowing areas that the 802.16 BSs cannot cover. The 802.11 network will be integrated into the 802.16 network rather than configuring a network by separating them. Hereinafter, IEEE may be omitted to refer standard specification.
A description will be made below of a conventional handoff between a WLAN and a broadband wireless communication network.
FIG. 1 illustrates a conventional system model in which the 802.11 network coexists with the 802.16 network. The 802.11 network and the 802.16 network operate separately.
In contrast to the 802.11 standard which has not specified handoff between 802.11 APs, the 802.11f draft provides a simple definition of handoff. In order to  support a handoff between the 802.11 APs, communications should be enabled between them by the use of an item called a Wireless Switch (WS) and messages defined by the 802.11f draft. Meanwhile, an 802.16 handoff is performed in the manner defined by the 802.16e draft.
The terms used herein “handoff between homogeneous networks” and “horizontal handoff” are interchangeably used with the same meaning, and “handoff between heterogeneous networks” and “vertical handoff” are also interchangeably used with the same meaning. In addition, the 802.11 network and the 802.16 network are called “WLAN” and “broadband wireless communication network”, respectively.
Now a description will be made of a conventional handoff technique based on the above description.
Horizontal Handoff Between IEEE 802.11 APs
As described above, the IEEE 802.11 TG f specifies simple messages for handoff between APs. A Subscriber Station (SS) shall initiate a handoff procedure according to the 802.11f draft. A reassociation request message and a reassociation response message are defined to support handoff in the IEEE 802.11 standards. The reassociation request message further includes an old AP field in addition to an association request message, and the reassociation response message is identical to an association response message.
In the handoff procedure as provided by the 802.11f draft, the SS dissociates from an old AP and reassociates with a new AP. The 802.11f defines an Inter-Access Point Protocol (IAPP) which defines messages exchanged between APs, for handoff. Such IAPP messages include IAPP ADD-notify, IAPP MOVE-notify, and IAPP MOVE-response. 
Table 1 below illustrates the format of the IAPP ADD-notify message.
TABLE 1InformationSize (bytes)NotesMAC Address6Address of Mobile SubscriberStation (MSS)Sequence Number2Sequence number of associationrequest frameTimeout2Timeout period
Table 2 illustrates the format of the IAPP MOVE-notify message.
TABLE 2InformationSize (bytes)NotesMAC Address6Address of Mobile SubscriberStation (MSS)Sequence Number2Sequence number of associationrequest frameOld AP6Address of old APTimeout2Timeout period
Table 3 illustrates the format of the IAPP MOVE-response message.
TABLE 3InformationSize (bytes)NotesMAC Address6Address of Mobile SubscriberStation (MSS)Sequence Number2Sequence number of associationrequest frameOld AP6Address of old APNew Basic Service6 or 8BSSID of new networkSet Identification(BSSID)
FIG. 2 illustrates a conventional handoff procedure in an 802.11 WLAN.
Referring to FIG. 2, an SS 280 associates with a first AP 250 by  association request and response messages in step 211. The first AP 250 transmits an IAPP ADD-notify message to a WS 210, notifying the entry of the S 280 into the first AP 250. The WS 210 multicasts the IAPP ADD-notify message to APs within the same domain in step 215. It is assumed that a second AP 270 is located in the same domain.
When the SS 280 moves to the second AP 270, i.e. a handoff to the second AP 270 is requested in step 217, it transmits a reassociation request message to the second AP 270 and receives a reassociation response message for the reassociation request from the second AP 270 in step 219.
As the SS 280 has associated with the second AP 270, the second AP 270 transmits an IAPP MOVE-notify message to the first AP 250 via the WS 210 in step 221. The first AP 250 dissociates from the SS 280 in step 223 and transmits an IAPP MOVE-response message including information about a requested context to the second AP 270 via the WS 210 in step 225. In this way, the handoff is completed.
Horizontal Handoff Between IEEE 802.16 BSs In the IEEE 802.16 network, initialization between a base station (BS) and a subscriber station (SS) (or MSS) is based on IEEE 802.16-2004 and horizontal handoff is implemented in compliance with the IEEE 802.16e draft.
FIG. 3 is a flowchart illustrating a conventional handoff procedure in an 802.16e broadband wireless communication network.
Referring to FIG. 3, at an initialization or when a signal is disconnected from a BS, an SS selects a cell (or BS) to camp on by downlink channel scanning in step 301. For example, the SS scans successive downlink channels starting with the latest received channel until a valid downlink signal is received. 
After the cell selection, the SS acquires physical synchronization using the preamble of a downlink (DL) frame received from the selected BS in step 303. If a DL-MAP and a Downlink Channel Descriptor (DCD) are received successfully, it is considered that synchronization with the BS has been acquired.
The SS receives an Uplink Channel Descriptor (UCD) from the BS and acquires uplink parameters from the UCD information in step 305. Based on the uplink parameters, if its determined that the uplink is not available to the SS, then the SS starts channel scanning for another channel. However, if the uplink is available, the SS waits for the next DL-MAP and UL-MAP and checks an initial ranging area allocated by the BS.
In step 307, the SS performs ranging. Specifically, the SS transmits an RNG-REQ message to the BS according to the initial ranging area. The RNG-REQ message is formatted as follows.
TABLE 4InformationSize (bytes)NotesManagement Type1ID (4) identifying RNG-REQDownlink Channel ID18-bit ID of downlink channelTLV Encoded InformationvariableMAC address, version,capability of SS
The SS initially transmits the RNG-REQ message at a minimum power level, but if not receiving a response from the BS, it gradually increases the power level. The BS replies to the RNG-REQ message with RNG-RSP, allocates a Connection ID (CID) to the SS, and allocates an individual initial ranging area for correcting a transmission power level and a timing offset to the SS. The structure of RNG-RSP is illustrated in Table 5 below. 
TABLE 5InformationSize (bytes)NotesManagement Type1ID (5) identifying RNG-RSPUplink Channel ID18-bit ID of uplink channelTLV Encoded InformationvariableTiming control information,power control information,basic CID
The SS then exchanges RNG-REQ and RNG-RSP with the BS through the individual initial ranging area, thereby adjusting the transmission power and timing.
After the ranging, the SS negotiates basic capabilities with the BS by exchanging SS Basic Capability Request (SBC-REQ) and SS Basic Capability Response (SBC-RSP) in step 309. Table 6 below illustrates the format of SBC-REQ.
TABLE 6InformationSize (bytes)NotesManagement Type1ID (26) identifying SBC-REQTLV Encoded InformationvariableCapabilities supported by SS
Table 7 below illustrates the format of SBC-RSP.
TABLE 7InformationSize (bytes)NotesManagement Type1ID (27) identifying SBC-RSPTLV Encoded InformationvariableCapabilities supported byBS among SS-requestedcapabilities
In step 311, the SS performs authorization and exchanges keys. The SS then associates with the BS by exchanging Registration Request (REG-REQ) and  Registration Response (REG-RSP) with the BS in step 313.
Table 8 below illustrates the configuration of the REG-REQ message.
TABLE 8InformationSize (bytes)NotesManagement Type1ID (6) identifying REG-REQTLV EncodedvariableMessage authentication codeInformation(MAC), uplink CID, IPinformation, and SSmanagement information
Table 9 below illustrates the format of the REG-RSP.
TABLE 9InformationSize (bytes)NotesManagement Type1ID (7) identifying REG-RSPResponse1Indicates whether REG-REQreception is successfulbased on MACTLV Encoded InformationvariableResponse to managementinformation of REG-REQ
Following the registration, the SS establishes an IP connection in step 315. That is, the SS negotiates an IP version that the BS supports, and is allocated an IP address by a Dynamic Host Configuration Protocol (DHCP) mechanism, that receives date and time for the time stamp of log files. In step 317, the SS transmits operational parameters to the BS. Steps 315 and 317 are optional.
When the initialization procedure is completed in this way, the SS establishes a connection in step 319 and operates normally by the connection in step 321. During the normal operation, the SS searches neighboring BSs by  channel scanning at predetermined intervals.
Later, if a handoff is determined, the SS terminates the connection to the old BS (or source BS) in step 327 and selects a target BS in step 329.
In steps 331, 333 and 335, the SS performs a new network entry for the target BS in a similar manner to the above-described initialization procedure. The new network entry involves the process of searching for a cell offering a high Signal-to-Interference plus Noise Ratio (SINR) without association, before normal registration to the cell. Hence, the old BS does not know the movement state of the SS.
When finally deciding on the target BS, the SS performs re-authorization in step 337 and carries out re-registration and re-establishes service flows in step 339. Thus, the SS associates with the target BS in step 339. In step 341, the SS operates in a normal manner by the connection to the new BS.
Meanwhile, the SS can re-establish an IP connection in step 343. In case of a “make-before-break” handoff, the SS terminates every connection to the old BS in step 345.
The IEEE 802.16e working group is working on standardizing mobile wireless MAN for supporting the mobility of the SS, while keeping backward compatibility with the 802.16 standards. To a Mobile SS (MSS), a BS broadcasts a Neighbor Advertisement (MOB_NBR-ADV) message including information about neighboring BSs to all MSSs within the cell coverage. Table 10 below illustrates the structure of the MOB_NBR-ADV message.
TABLE 10InformationSize (bytes)NotesManagement Type1ID (53) identifyingMOB_NBR-ADVOperator ID3Unique network IDConfiguration1Increases by 1 each timeChange Countbroadcast data is changedN_NEIGHBORS1The number of neighbor BSsEach NeighborvariableBS ID, preamble index, PHYinformationprofile IDHO Process1Information about processesOptimizationthat can be omitted at re-entry
The MSS transmits a Scanning Interval Allocation Request (MOB_SCAN-REQ) message to the serving BS to search neighboring BSs for handoff and determines a neighboring BS's scanning interval based on a MON_SCN-RSP message replied for the MON_SCN-REQ message. Without a request form the MSS, the BS can allocate a neighboring BS's scanning interval. Table 11 below illustrates the configuration of the MON_SCN-REQ.
TABLE 11InformationSize (bytes)NotesManagement Type1ID (54) identifyingMOB_SCN-REQScan Duration1Scanning intervalInterleaving1Overlap between normalIntervaloperation intervaland scanning intervalScan Iteration1The number of iterativescanningsMessage21MAC ensuring integrityAuthenticationCode (MAC)
The format of MOB_SCN-RSP is given in Table 12 as follows.
TABLE 12InformationSize (bytes)NotesManagement Type1ID (55) identifyingMOB_SCN-RSPScan Duration1Scanning intervalStart Frame4bitsScanning start frameInterleaving1Overlap between normal operationIntervalinterval and scanning intervalScan Iteration1Number of iterative scanningsReport Mode2bitsMode of reporting measurementto BSMessage21MAC ensuring integrityAuthenticationCode (MAC)
IEEE 802.16e will define a “break-before-make” handoff in which an old channel is released before connection of a new communication channel and a “make-before-break” handoff in which disconnection of an old channel follows connection of a new channel. Yet, at present, standardization documents are mainly focusing on the “break-before-make” handoff.
FIG. 4 is a diagram illustrating a signal flow for a conventional overall handoff procedure in the 802.16 broadband wireless communication network. While handoff initiation can occur in both the BS and the MSS, the MS initiates a handoff in the illustrated case of FIG. 4.
Referring to FIG. 4, an MSS 410 acquires neighbor BSs 470 and 490 by frequency channel scanning and determines whether to implement a handoff by measuring received signal strengths form the neighbor BSs 470 and 490. If the MSS 410 decides on a handoff, it transmits a MOB_MSSHO-REQ message including information about the neighbor BSs 470 and 490 as candidate target BSs to a serving BS 450. Table 13 below illustrates the MOB_MSSHO-REQ.
TABLE 13InformationSize (bytes)NotesManagement Type1ID (57) identifyingMOB_MSSHO-REQN_Recommended4bitsNumber of BSsthat MSS setsas candidatesEach Candidate BSvariableBS ID, preamble index,InformationSINR, etc.Message21MAC ensuring integrityAuthenticationCode (MAC)
Upon receipt of MOB_MSSHO-REQ, the serving BS 450 transmits a HO-pre-notification message to the candidates BSs 470 and 490, notifying the handoff of the MSS 410 in steps 413 and 415. Simultaneously, the serving BS 450 informs them of the MSS ID, connection parameter, capabilities, requested BandWidth (BW), and QoS information of the MSS 410. In steps 417 and 419, the candidates BSs 470 and 490 transmit an ACKnowledgement in a HO-pre-notification-response message to the serving BS 450.
Meanwhile, the serving BS 450 determines a target BS based on information included in the HO-pre-notification-response message. It is assumed herein that the BS 490 is selected as the target BS. The serving BS 450 then transmits an HO-confirm message to the target BS 490 in step 421 and notifies the MSS 410 of the target BS 490 in a MOB_BSHO-RSP message in step 423. The present 802.16e draft has not defined the message format of HO-pre-notification. Table 14 below illustrates the format of the MOB_BSHO-RSP.
TABLE 14InformationSize (bytes)NotesManagement Type1ID (58) identifyingMOB_BSHO-RSPN_Recommended1Number of BSs that MSS setsas candidatesEach Candidate BSvariableStore BS ID, preamble index,InformationHO process optimizationinformation in BS-recommended orderNew_BS InformationvariableInformation about BS thatserving BS recommendsamong BSs that MSS has notselected as candidatesMessage21MAC ensuring integrityAuthenticationCode (MAC)
In step 425, the MSS 410 notifies the serving BS 450 of normal handoff completion in MOB_HO-IND. The serving BS 450 releases resources and a connection from the MSS 410 in step 427. The MSS 410 can cancel the handoff by a predetermined field of the MOB_HO-IND message or reject a handoff recommended by the serving BS 450.
In step 429, the MSS performs fast ranging based on known information about the target BS 490. The MSS 410 then enters a new network in steps 431 and 433, in the manner described with reference to FIG. 3. Table 15 below illustrates the configuration of the MOB_HO-IND.
TABLE 15InformationSize (bytes)NotesManagement Type1ID (59) identifyingMOB_HO-INDHO-IND_type2bitsIndicates one of serving BSrelease, HO cancel, and HOrejectMessage Authentication Code21MAC ensuring integrity(MAC)
As described above, the present IEEE 802.11 and 802.16 standards define handoff between homogeneous networks, not yet handoff between heterogeneous  networks. The 802.11 APs will increase the capacity of the 802.16 BSs or cover shadowing areas that the 802.16 BSs cannot cover. The integration of the 802.11 network into the 802.16 network requires an efficient handoff technique between the 802.11 and 802.16 networks.